I don't think we want to prescribe OpenID Federation as the only way metadata could be resolved from the client ID when it is an HTTPS url. There are multiple well-known metadata locations proposed for client metadata and a similar precedent exists within OAuth/OpenID for IDP / Authorisation Server metadata.

The intention is that federation is the only thing that uses the https client id scheme, and this doesn't stop a well-known based client id scheme being created, it would just use a client_id like wellknown:https://rp.example.com/.

If you think the text isn't conveying this could you suggest alternative wording please?

That doesn't reflect the intention though. If people want to use https urls with a different resolution method, they use a client id scheme other than https, e.g. wellknown:https://rp.example.com/. The "https" client-id scheme is reserved for federation only.

Avoiding the vagueness of "I'm going to somehow authenticate with you using this url, you go figure out how you think I'm trying to authenticate with you" is very much the point. If you think of the browser API, using the https client id scheme to reflect multiple ways the wallet can authenticate, can result in lots of deadends as the sandboxed wallet matcher is now unable to know if it supports the method the wallet is using to authenticate, because it literally doesn't know how the wallet is trying to authenticate and has no way to find out because it can't access the network.

@selfissued I'll change this to a "MUST NOT be prefixed" to be very clear.

@tplooker @jogu I agree with Joseph here. This is an opportunity to have a clearly defined mechanism both from a security point of view and from an implementation perspective. Unless there is a good reason to not prefix other https-based client id schemes, we should avoid it.

Federation is an overly complicated mechanism for a client to simply convey its metadata at a well-known location, I don't believe we should be promoting it as the preferred mechanism for clients that are choosing to identify via an HTTPS url which is what this proposal does. It relegates other HTTPS based url based client metadata discovery mechanism to requiring a double prefix style client id which I don't think is a clean solution.

If we would prefer to have less ambiguity then the text I suggested, I propose we have a seperate parameter to convey the metadata location for the client such as client_metadata_location=federation.

@tplooker Is it going to be any different than client_id_scheme for https-based urls?

Just to be clear, we are not promoting federation as a preferred mechanism. We are merely acknowledging that federation is already the long established way of client's using self-allocated client_ids beginning with https: and that there's not really any option open to us of changing that position.

The alternative (following in the vein of this PR) is that federation is also prefixed, but that introduces interoperability issues / confusion and still doesn't solve the 'clean solution' problem.

I think if we do want to do something that is a generic scheme based on https urls (and I think that could be a good idea), we need to do that with a prefix, otherwise we're going to overlap and/or conflict with at least two other different specifications. It's simply not sustainable or sensible to have multiple specs trying to define self-assert client ids that are pure https urls. Even federation probably shouldn't be doing it, but that ship has mostly sailed.